Key value store as usual like one described in drawing 1 and non-patent document 1, was merely a database resource as a simple collection of key value elements, which is a combination of values and keys (ID) which identify the values. It is utilized in WEB sites which gather text information on a global scale over the Internet and store it as key value type data, in order to search text with criteria “containing text” while it also is utilized in Electric Commerce WEB sites which keep data of the world's books and inventory search upon customers' request within WEB sites. In most sites, they utilize recorded text data as a value and find the key value data that holds text data as a portion which matches the search key within to make a list of keys that match the key value data, so that they assort on user demands and display by re-keying database resources in the key list
This key value store, as shown in drawing 1, because of its simplicity, is easy for horizontal partitioning of database resources, and can have an excellent feature if we use it to disperse partitioned database resource to relatively huge numbers of small server computers and treated them as one giant search-wise database system.
It is indicated in the non patent document 1 how in horizontal partitioning of the database resource which comprises key value type data that uses a lot of unique ID as a key, the method on computer servers in order to store and manage database resources above divides into a physical-database group using a hash function etc., meeting the storage capacity of the server computer for storing, and the technique of arranging said database resource directly in order the server calculation on a plane which carries out storing management.
However, either when the server computers which carry out storing management of said database resource need to be reduced by means of such failure during operation, or when the server computer which carries out storing management of said database resource by means of such scale expansion etc., many database resources must be made moved. The method of minimizing movement of a database resource is indicated in the patent document 2 that; instead of using a hash function etc., when dividing to meet the storage capacity of the server computer for storing, said database resource is divided into the logical database group of about 1/10 size from the third of the storage capacity of the server computer which carries out storing management, so that; a table to which the server computer group which carries out storing management of said one or more logical database group groups and said one or more database resources is made to correspond is utilized to arrange.
The distributed database dispersed and arranged at the large scale database or the physically distant place, by dividing into two or more domains, having one or more database management systems in the topology server in each domain, and exchanging the meta information between each topology servers, the distributed database system with the real time update performance in practical use as well as data consistency by exclusive control or reference nature consistency is indicated in the patent document 1.
Said meta information is not exchanged for each meta information, instead the partition cash art of sharing main memory unit space between topology servers through/or the replication cash technology which reproduces and has main memory unit space between topology servers are used, the method of attaining highly efficiency of a distributed database system with the real time update performance in practical use as well as consistency is indicated in the patent documents 3. In multi-transaction processing in these patent documents 3, besides collateral data consistency by exclusive control or reference nature consistency, do the counter rise of by an update request, and the counter down of is done by updating success, the table to which the server computer group which carries out storing management of a counter, and said logical database groups' group and said database resource for judging the time of returning to zero that the update of the whole transaction was successful is made to correspond, how to realize by distribution-sharing or duplicate sharing between the topology servers of each domain is also indicated.
When the mainstream of the database changes from the network-type database to the relational database, in early the 1980s, The badness of the throughput by the low level of the performance of a relational database, especially the performance of JOIN processing had become a problem with the poor access speed and capacity of the low level of the CPU performance of the computer for carrying out management storing of the database of those days, and a main memory unit and a secondary memory. In order to avoid the problem, there were the time when it was allowed to be said that it is better not to normalize, on the other hand, they are remnants of the architecture of a network-type database as the avoiding means, perform a bonding process beforehand at the time of ROW(row, a tuple, or a record) insertion through/or updating, and the location information by a pointer is held, when a actual bonding process was required, the technique named “pre-joining” in the meaning of “combining of forecast” that the location information by the pointer performs a bonding process at high speed was used by some relational databases. The structure is indicated in drawing 2. There shall be the refer passive table (relation) 10 and refer positive table 20, where table 10 has the COLUMN (columns, an attribute, or the field) 11 and 12, and the primary key is attached to the column 11, so that each record of the table 10 has unique key. In addition, the refer active table 20 shall also have the column 21 and the column 22, and the external reference key (FOREIGN KEY) shall be set to the column 11 at the column 22. There is the special column 15 which stores row ID of the record in the refer active table 20 currently referred to at the special column 14 and the last which store line ID of the record in the refer active table 20 which is referring to the record with the refer passive table 10 first, and while there is the special column 26 which stores row ID of the record in the refer active table 20 which is referring to the record concerned of the special column 25 which stores row ID of the record in the refer active table 20 which is referring to the record concerned of the refer passive table 10 previously, and the refer passive table 10 behind, where it is possible for the collection set of the record in the refer active table 20 which refers to the record concerned of the refer passive table 10 to come to hand. Moreover, the special column 16 for the convenience which stores the number of the record in the refer active table 20 specified as the element of this collection set is shown in the refer passive table 10, and the special column 24 which stores row ID of the record in the refer passive table of a reference destination is shown in the reference table 20. This structure has made the relations between refer active and refer passive tables can be held flexibly and can acquire at high speed as well as “pre joining” enabled.